EnigmA Amiga Run 1995 November/EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso/earcd/docs/lwml9502.lha/Lightwave-Feb95/000538_owner-lightwave-l _Mon Feb 27 01:46:46 1995.msg

Internet Message Format | 1995-03-19 | 11KB

Return-Path: <owner-lightwave-l>
Received: by mail4.netcom.com (8.6.9/Netcom)
    id VAA10203; Wed, 22 Feb 1995 21:29:53 -0800
Received: from zevs.ifi.unit.no by mail4.netcom.com (8.6.9/Netcom)
    id VAA10100; Wed, 22 Feb 1995 21:29:19 -0800
Received: from uranus.ifi.unit.no by zevs.ifi.unit.no with SMTP id AA26797
  (5.67b/IDA-1.4.4 for <[e-mail]>); Thu, 23 Feb 1995 06:30:13 +0100
Received: by uranus.ifi.unit.no (4.1/Uninett-C-1.4)
    id AA03215; Thu, 23 Feb 95 06:30:11 +0100
Date: Thu, 23 Feb 1995 06:30:10 +0100 (MET)
From: Ole Andre Schistad <[e-mail]>
To: [e-mail]
Subject: Open suggestion to NewTek regarding IK and general physics.
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

  The word on the grapevine is that the people at NewTek are open for
suggestions for LW4.0 , and that they read this list. In the hope of seeing
at least some of the features I will mention here , I will try to throw all
the suggestions I've been sitting with at you people :)

  I think everyone who use LW and/or the toaster will agree that there's really
just one or two major features that are lacking ; namely procedural textures
and some kind of kinematics. The former , I believe , will be achieved
through plug-in modules. (God , I hate that word , it's been a catch-phrase
on everyone's lips ever since it became publicly known that LW4.0 would have
them :-/ ). The latter , however , deserves integration into the main
interface. Now , before you all go ``Who needs all that fancy physics shit
in LW anyway ? That's real3d V2 territory , and you know it!'' I want you
to consider just what the lack of physics of any kind means.

  The human being has an amazing ability to do trajectory calculations by
intuition .This is no wonder , as we've been throwing things around for
thousands of years. When you pick up a stone and throw it at a lightpost ,
you never consider gravity and weight consciously, and yet you still hit it.
A good pitcher can place a throw within an inch from where he's aiming,
and even more amazingly , a good batter actually HITS that screaming 70+ mps
blur of motion. Tough shit, you say , can I finish my render now please ?

  So what IS that animation anyway ? Is it a work of art , or just an attempt
to recreate a small piece of reality ? I believe it's both. More than
anything , though , we are making ILLUSIONS.. and as any good magician
could tell you , an illusion must be credible to work. But if your objects
are doing things that simply aren't possible in our world, the watcher
balks.. the illusion is broken and (s)he realizes that it was all just
special effects .. make believe .. lies. A good animator avoids that
pitfall, but it almost always takes a lot of tweaking. I'm sure you know
the feeling .. ``How DOES it move anyway ? THAT sure as hell didn't look
right!'' .

  Which brings me back to the central issue : An intuitive and easy way to
animate the way nature does. This is also where I will start getting
technical so please bear with me.

  The first thing I learned as a physics student was simplification. By
themselves , the rules that govern our universe are so complex that a mere
human could not hope to take them all into consideration.. even newtonian
physics is enough to drive you out of your mind if you have to consider
all the equations at once. What you do instead is to look at the cases
separately , and as simplified as you can possibly get them. It all boils
down to a set of forces that act upon an object (or body) . Each of those
forces act in ONE direction each . When you know all the forces that act
on a body , you can further narrow everything down to one single force acting
upon your object ; a force whose value and direction can be regarded as a
vector.

  To illustrate my point , let's say you have two planets orbiting the sun.
You know that all of those three bodies affect each other with a
gravitational force that's inversely proportional to their relative distance
from each other (F = gamma * Mm/dd , where gamma is the gravitational
constant ) . In addition , you have the force that keeps the planets from
falling into the sun ; this is the (rather incorrectly named) centrifugal
force ( F = vv/d ; velocity by the power of two , divided by distance)
So you have four vectors that apply to each of your planets ; current
movement (that is , speed and direction) , gravity from the sun , gravity
from your other planet , and inertia (centrifugal force).
                      4
                     '`  planet
  ___                || /
 /   \               ||/
| sun |       1 <====()====>2
 \___/               ||
                     `'
                      3





                     ()-- Planet 2


Okay , so let's consider the equation in two dimentions ..
You have the vector-set [-3,0] , [3,0] , [0,-1] and [0,25] (vector 4 is the
planets speed , which is not a force.) You want those three forces
simplified into one , so you add them together :

[-3+3+0 , 0+0-1] = [0,-1] ; voila! you have your single vector that sums
                            up all the forces acting on the planet .


  Now let's go one step further ; suppose we know that force .. how does it
affect our object ? All objects have a mass , or more generally , a mass
distribution . Actually , mass is never distributed uniformly , but
rather as a random variation in density that usually sticks close enough
to a normalized `mass-per-volume' that we can regard it as uniform.

  The beauty of it all though is that for all practical purposes
you can regard that mass as centered at one point; the center of mass.
And when you know an objects center of mass , you can very easily calculate
how an object is affected by a given force , *including its rotation* !

  Attracting and repulsing forces act on the center of mass directly , and
generate a change in direction and speed . Things get slightly more
complicated when you're dealing with collisions , because the forces
involved no longer act on the center directly ; they act where two bodies
intersect. (No pun intended , a body is per definition an object that has
mass and size larger than zero :-)) . The big secret is ; where did the
bodies intersect ? When you know that , you're home free - almost.


__________________________  This is how it looks when you consider just
|                        |  one of the bodies ; X marks the center of mass,
|            X           |  and I is the force that's affecting it.
|                        |
|________________________|<====
                             I


(What I've tried to draw here is an off-center impulse)

In order to calculate the change in rotation and velocity , you draw
a line from X to the intersection point. Find the angle between that line
and vector I , find the components in all three dimentions , and you know
how the body will move. I would give the equations , only it's been three
years since I left my physics studies , and the only physics book I was able
to dig up was modern physics (no need to get Eisteinian yet :-) - rather
embarrassing really :( . The calculations should take FAR less than a second
on any machine quipped with an FPU.

  So far so good. None of this should be new to Allen and the other people
at NewTek. The big question is that of the implementation , and I tell
thee straight ; stick that center of mass into your object format , and
the job is already half done! :) What I have in mind is to keep the heavy
calculations where they belong ; in modeler. Let's presume that the world is
perfect , and that all objects have a uniform distribution . Calculate
the geometric center of an object , and you get the center of mass.
That's the only really heavy equation you need , the rest can be done almost
real-time in layout.


  What we want from a `physics' addition to LW is the POSSIBILITY to add
real-life motion to our objects , not the necessity to take it into
consideration. This means that there must be a way to turn physics off,
and leave everything in the capable hands of the user.

  Also , the concept of `force' does not exist in LW at this point , but
you can use Newtons 2nd law ( F=ma ) since you always know the velocity of an
object.  What I have in mind is to separate objects into two or three
cathegories. I believe the best way to handle the concept of force is to let
all forces originate in objects or null-objects. Once an object is set up as
an originator of force (Simple button+value in the objects menu)
it can either  default to receiving forces from other objects , or you
can totally abstract by leaving that too up to the user. All other objects are
unaffected by force , and I don't think I need to explain why.

  A more crucial consideration is that of collision detection , as it could
potentially wreak havoc on layout . Again , I do not think it would be a
good idea that all objects are taken into account when you want to check for
collisions , because when polygon count goes into the thousands it would
take forever if you had to check for collision against all of them.

  The best approach would perhaps be to limit collision detection to
`physically receptive' objects (that little button in the objects menu  :).
Whenever the user moves a receptor , you check for collision detection
along the path from the last known position , and if one has occurred you
can prompt the user with a simple yes/no requester asking wether or not to
calculate new trajectories . This means that while physics are turned on and
the user is manipulating a `receptive' object , he is giving trajectory
input , not absolute positions . (`I want this object to move along a path
that would take it to this point unless it hits something else'). You
could even keep the physics on a frame-by-frame basis and keep velocity
vectors constant after physics are turned off.

  As an alternative to collision detection , you could let the user target
two or more objects together as `physically interactive' . Whenever one
object is moved , the other connected objects are moved and rotated based
on how their respective centers of mass are located in relation to an
anchor point . I haven't worked out quite how this should work , as
I regard collision detection as instrumental if you want any kind of
realistic behaviour.


And that concludes this rather lengthy mail :)

- Ole Andre Schistad